home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 5123 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.8 KB
  1. Path: news.flinet.com!usenet
  2. From: kristof@flinet.com
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: My test results for USR Sportster 33.6kbps
  5. Date: 21 Feb 1996 19:07:53 GMT
  6. Organization: Florida Internet
  7. Message-ID: <4gfqi9$f0s@news.flinet.com>
  8. References: <4g7ok3$74j@pathway1.pathcom.com>
  9. NNTP-Posting-Host: wpb71.flinet.com
  10. X-Newsreader: AIR News 3.X (SPRY, Inc.)
  11.  
  12.  Hi,
  13.  
  14.   Ladies and gentlemen! We have one 'response' to my test results here.
  15.   I believe he considers himself  an 'expert' in taking 2 PC's with modems,
  16.   and running primitive file transfers to measure simple throughput. 
  17.   Obviously, he is not capable of doing it himself and tries to nitpick.
  18.   Quite frankly, I expected more technical responses. There are
  19.   many factors to consider but this response does not even get 
  20.   close to them. But I will respond and it will be the last time
  21.  
  22. >   insystem@pathcom.com (Geoffrey Welsh) writes:
  23. >  In article <4fv36j$lvj@news.flinet.com>, kristof@flinet.com wrote:
  24. >  >I tried to evaluate the performance of the USR Sportster 28.8 V.34
  25. >  >with 33.6kbps upgrade (purchased recently for just under $200).
  26. >  >Just to check how much this new 33.6kbps V.34bis effort is worth in 
  27. >  >the reality of US residential analog lines.
  28. >  
  29. >  It's wonderful that you did this, but one of your comments reveals that you're 
  30. >  not very familiar with the stuff that you're testing.  This doesn't make the 
  31. >  test invalid; after all, you don't have to be a mechanic to test drive a car!
  32. >  
  33.  
  34.    I think you failed to notice that this testing is not a brain surgery but
  35.    a simple and reliable throughput evaluation. The comments you're referring to
  36.    had nothing to do  with the test. Again, direct your efforts to the subject
  37.    at hand.  Your response does not include even one relevant observation
  38.    and you seem to consider yourself an 'expert' in area you
  39.    cannot correlate very well.
  40.  
  41. >  >I used 120MHz and 75Mhz Pentium PC's, each with internal USR.
  42. >  >All transfers were done with the popular QuickLink II communication
  43. >  >program included with USR and many other modems on the market.
  44. >  >The port setting in QuickLink was 115,200-8-N-1, RTS/CTS  in both PC's.
  45. >  >The modems init strings was just ATZ4, i.e. the normal hardware profile.
  46. >  
  47. >  Well, QuickLink is only popular because several manufacturers give it away.  
  48. >  Nothing wrong with that, I just had to get my 2 cents in...
  49. >  
  50.  
  51.   This is probably the most ignorant observation which is common among
  52.    the uneducated. First, realize one thing again. The test did not require 
  53.    any sophistication in a comm program. It was a primitve file transfer
  54.    with a straight  ASCII and ZMODEM protocol which is so trivial that
  55.    every student in programming can write easily. No advanced
  56.    brain surgery is required. If you state your objections then you have to back
  57.    them up. Compare with another comm program and state the performance
  58.    differences to show how they would affect the test. If you are not able to 
  59.    back up your childish potshots then keep them to yourself.
  60.  
  61.  
  62. >  >[...] However, for some strange reason, disabling ARQ LAPM
  63. >  >degraded the throughput by about 15-20%. Consequently, all test cases
  64. >  >used ARQ/LAPM/V.42bis.
  65. >  
  66. >  LAP-M (the primary error correction protocol in V.42) and MNP service class 3 
  67. >  do not send start and stop bits because they are unnecessary when the data is 
  68. >  transmitted using a synchronous carrier and protected by a CRC.  In theory, 
  69. >  this should boost throughput by 25%, since you're dividing the carrier speed 
  70. >  by 8 in stead of 10... however, the error correction protocol does have some 
  71. >  overhead, so the gain is less than 25%... about 19%, assuming no retransmits.
  72.  
  73.   This is great and it would explain the degradation. But I would like to hear the
  74.    background from a person  with more technical  credibility in modems technology.  
  75.    Your  unsubstantiated objections to the test disqualify you from  giving any technical
  76.    advice. 
  77.  
  78. >  
  79. >  >[...] However, I tried to spend some time looking
  80. >  >into the compressing capabilities of V.42bis and compare with
  81. >  >the DOS utilities like COMPRESS, PKZIP, or LHA. V.42bis could not
  82. >  >match PKZIP or LHA, but it was better than COMPRESS (from Microsoft).
  83. >  
  84. >  Keep in mind that V.42bis has many limitations: it must be 'instant'; it must 
  85. >  run in very little ROM and RAM; it must run on a relatively feeble CPU; it 
  86. >  cannot change its mind on what it's going to do and go back.
  87. >  
  88.  
  89.    I did not ask for explanations about the V.42bis compressing abilities.
  90.    It is common for the standards to be behind the state of the art.
  91.    And the real  factors are complex and well beyond  your comprehension.
  92.  
  93.  
  94. >  >Some very redundant files were compressed so much that the
  95. >  >serial port rate 115,200 bps was a bottleneck and was slowing the
  96. >  >modem transmission considerably. 
  97. >  
  98. >  Yep... as I've pointed out recently, for a demonstration of V.42bis' 
  99. >  effectiveness on ridiculously compressable data, lock your serial port to 
  100. >  115200 bps, lock your carrier to 1200 bps, and send ten megabytes of nulls.
  101. >  
  102.  
  103.   What  is this 'comment' supposed to mean?  Is it supposed to indicate
  104.   your 'knowledge'  of compression techniques. I just simply implied
  105.   that the serial port and comm program were  set up  to handle much higher speeds
  106.   than the maximum DCE-DCE throughputs I was running at.  My capability to generate
  107.   files with different degress of compressability  is well  above using   a 
  108.   series of nulls which is probably what you are limited to.
  109.  
  110.  
  111. >  >[...] All the files I tested with were
  112. >  >1MB, i.e. the transfer times were at least 4-5 mins.
  113. >  
  114. >  This is very good, and very important.  Also, I hope you used the _recevier's_ 
  115. >  CPS rate, not the transmitter's.
  116. >  
  117.  
  118.   What is important  is well beyond your understanding and technical
  119.   background.  What you hope for  is well beyond your abilities either?
  120.   The file transfer started ' instantaneously' on both sides and
  121.   completed with the last received character. The file size and
  122.   transfer time ensured that the startup times were kept to a 
  123.   minimum.
  124.  
  125.  
  126. >  >All initial connects were 33,600 on both sides. After each file
  127. >  >transfer, the ATI6 displayed 33,600/33,600 on both sides.
  128. >  >
  129. >  >The real/effective throughput (again V.42bis was not able to compress) 
  130. >  >     ZMODEM 31,550 bps
  131. >  >     ASCII          31,870 bps
  132. >  
  133. >  You mean, 3155 and 3187 CPS?  That's _not_ impressive.  Between two Courier 
  134. >  33.6 modems I've seen ZedZap CPS rates in the 3800 range.  They're rare, but 
  135. >  they do happen from time to time.
  136. >  
  137.  
  138.   Is it the last  'insightful' comment?  You kind of implied you had a higher throughput.
  139.   Why don't you post the testing details?  Or you simply base your claims on a
  140.   'gut feeling' or even worse .... CONNECT message.  Instead of educating 
  141.   yourself,  you just spend your  time nitpicking  and wasting everybody's time.
  142.  
  143.  
  144.  
  145.   Chris
  146.  
  147.  
  148.